gh-153631: Move to macos-26 runner for iOS#153632
Merged
Merged
Conversation
freakboy3742
added
skip news
needs backport to 3.13
freakboy3742
requested review from
AA-Turner,
JacobCoffee,
ezio-melotti,
hugovk,
itamaro and
webknjaz
as code owners
ned-deily
approved these changes
Jul 13, 2026
|
Thanks @freakboy3742 for the PR 🌮🎉.. I'm working now to backport this PR to: 3.13, 3.14, 3.15. |
|
Sorry, @freakboy3742, I could not cleanly backport this to |
|
GH-153673 is a backport of this pull request to the 3.15 branch. |
bedevere-app
Bot
removed
the
needs backport to 3.15
|
Sorry, @freakboy3742, I could not cleanly backport this to |
|
GH-153674 is a backport of this pull request to the 3.14 branch. |
|
GH-153675 is a backport of this pull request to the 3.13 branch. |
freakboy3742
added a commit
that referenced
this pull request
Jul 13, 2026
) Switches iOS CI to use the macos-26 runner, and makes a small change to the iOS build script to improve build stability. xcodebuild doesn't guarantee that the CoreSimulatorService is running before starting a simulator. If the service isn't running, xcodebuild reports that no simulators are available, and fails to start the test app. However, simctl blocks until the simulator is available, and simctl is used to evaluate the default simulator. So - the iOS build script now unconditionally determines the default simulator, even if a specific simulator is requested. (cherry picked from commit 2dc1a91) Co-authored-by: Russell Keith-Magee <russell@keith-magee.com>
hugovk
pushed a commit
that referenced
this pull request
Jul 14, 2026
) Switches iOS CI to use the macos-26 runner, and makes a small change to the iOS build script to improve build stability. xcodebuild doesn't guarantee that the CoreSimulatorService is running before starting a simulator. If the service isn't running, xcodebuild reports that no simulators are available, and fails to start the test app. However, simctl blocks until the simulator is available, and simctl is used to evaluate the default simulator. So - the iOS build script now unconditionally determines the default simulator, even if a specific simulator is requested. (cherry picked from commit 2dc1a91)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Switches CI configuration to use macos-26 for iOS builds. macOS-14 is now in the deprecation window (with full deprecation by November); other Apple workflows are already on macOS-26.
This was previously proposed in #145099, but had to be rolled back due to a stability issue in the workflow. I've now identified the source of the stability problem.
The iOS simulator is managed by a daemon (CoreSimulatorService); and when the daemon is starting (or re-starting),
xcodebuildwill report that there are no simulators. It appears that Xcode doesn't block on the availability of CoreSimulatorService - it just returns an empty list if the service isn't running.You can verify this manually by running
python Platforms/Apple iOS ci --fast-cito build the framework and create a testbed project; then run:(substituting the testbed folder that was generated). In my testing (on an M5 MacBook), about 2 in 3 of those runs will fail, and only display the minimal iOS target list, not the full list of available devices.
However, if you run:
simctlbefore callingxcodebuild- it may take several seconds forsimctlto respond, but when it does, both simctl, and then and xcodebuild, will return a full list of devices.When running the Platforms/Apple script providing an explicit simulator, the first simulator call that is made is to
xcodebuildwith that specific simulator. However, if you fall back to the "default" behavior, the script callssimctlto determine the available simulators, which blocks untilCoreSimulatorServiceis running.As a side effect, it also means that the script is resilient to changes in simulator image. This will be a particular concern with the macOS-26 image, as Github has indicated that they're going to be more aggressive about updating the Xcode versions that are available, and more aggressive in pruning older versions. iOS 26.5 is the default today; it wasn't when the macOS-26 image was launched. Since there's no automated trigger for bumping Python's CI configuration, and there's a significant performance penalty to using a non-default simulator, using an automated discovery-based scheme seems prudent going forward.
I have now run the iOS CI step 15 times (on commit 078ed9a), and it has passed every time; see CI run history for details. Previously, it would always fail within at least 10 runs (see this comment)
I've also modified the testbed script to always determine the default simulator, even if that default isn't used; it's a cheap operation, but it should guarantee a simulator is available if someone does have an explicit simulator defined.